home *** CD-ROM | disk | FTP | other *** search
/ Amiga Plus 1995 #2 / Amiga Plus CD - 1995 - No. 2.iso / internet / rfc / rfc955 < prev    next >
Text File  |  1995-04-11  |  22KB  |  570 lines
  1.  
  2. Network Working Group                                          R. Braden
  3. Request for Comments: 955                                       UCLA OAC
  4.                                                           September 1985
  5.  
  6.                     Towards a Transport Service for
  7.                   Transaction Processing Applications
  8.  
  9.  
  10. STATUS OF THIS MEMO
  11.  
  12.    This RFC is concerned with the possible design of one or more new
  13.    protocols for the ARPA-Internet, to support kinds of applications
  14.    which are not well supported at present.  The RFC is intended to spur
  15.    discussion in the Internet research community towards the development
  16.    of new protocols and/or concepts, in order to meet these unmet
  17.    application requirements.  It does not represent a standard, nor even
  18.    a concrete protocol proposal.  Distribution of this memo is
  19.    unlimited.
  20.  
  21. 1.  INTRODUCTION
  22.  
  23.    The DoD Internet protocol suite includes two alternative transport
  24.    service [1] protocols, TCP and UDP, which provide virtual circuit and
  25.    datagram service, respectively [RFC-793, RFC-768].  These two
  26.    protocols represent points in the space of possible transport service
  27.    attributes which are quite "far apart".  We want to examine an
  28.    important class of applications, those which perform what is often
  29.    called "transaction processing".  We will see that the communication
  30.    needs for these applications fall into the gap "between" TCP and UDP
  31.    -- neither protocol is very appropriate.
  32.  
  33.    We will then characterize the attributes of a possible new
  34.    transport-level protocol, appropriate for these ill-served
  35.    transaction-processing applications.
  36.  
  37.    In writing this memo, the author had in mind several assumptions
  38.    about Internet protocol development.
  39.  
  40.       *  Assumption 1: The members of the Internet research community
  41.          now understand a great deal about protocols, and given a list
  42.          of consistent attributes we can probably generate a reasonable
  43.          protocol to meet that specification.
  44.  
  45.          This is not to suggest that design of good protocols is easy.
  46.          It does reflect an assumption (perhaps wrong) that the set of
  47.          basic protocol techniques we have invented so far is sufficient
  48.          to give a good solution for any point in the attribute space,
  49.          and that we can forsee (at least in a general way) many of the
  50.          consequences of particular protocol design choices.
  51.  
  52.  
  53.  
  54.  
  55. Braden                                                          [Page 1]
  56.  
  57.  
  58.  
  59. RFC 955                                                   September 1985
  60. Transaction Protocol
  61.  
  62.  
  63.       *  Assumption 2: We need to develop appropriate service
  64.          requirements for a "transaction processing protocol".
  65.  
  66.          The classifications "virtual circuit" and "datagram"
  67.          immediately define in our minds the most important attributes
  68.          of TCP and UDP.  We have no such immediate agreement about the
  69.          services to be provided for transaction processing.  The
  70.          existing and proposed transaction-oriented protocols show a
  71.          number of alternative choices [e.g., Cour81, BiNe84, Coop84,
  72.          Cher85, Crow85, Gurw85, Mill85].
  73.  
  74.    Many of the ideas discussed here are not new.  For example, Birrell
  75.    and Nelson [BiNe84] and Watson [Wats81] have described
  76.    transport-level protocols appropriate for transactions.  Our purpose
  77.    here is to urge the solution of this problem within the Internet
  78.    protocol family.
  79.  
  80. 2.  TRANSACTION PROCESSING COMMUNICATIONS
  81.  
  82.    We begin by listing the characteristics of the communication patterns
  83.    typical in "transaction processing" applications.
  84.  
  85.       *  Unsymmetrical Model
  86.  
  87.          The two end points of the communication typically take
  88.          different roles, generally called "client" and "server".  This
  89.          leads to an unsymmetrical communication pattern.
  90.  
  91.          For example, the client always initiates a communication
  92.          sequence or "transaction".  Furthermore, an important subclass
  93.          of applications uses only a simple exchange of messages, a
  94.          "request" to the server followed by a "reply" to the client.
  95.  
  96.          Other applications may require a continuing exchange of
  97.          messages, a dialog or "conversation".  For example, a request
  98.          to read a file from a file server might result in a series of
  99.          messages, one per file block, in reply. More complex patterns
  100.          may occur.
  101.  
  102.       *  Simplex Transfers
  103.  
  104.          Regardless of the pattern, it always consists of a series of
  105.          SIMPLEX data transfers; at no time is it necessary to send data
  106.          in both directions simultaneously.
  107.  
  108.  
  109.  
  110.  
  111.  
  112. Braden                                                          [Page 2]
  113.  
  114.  
  115.  
  116. RFC 955                                                   September 1985
  117. Transaction Protocol
  118.  
  119.  
  120.       *  Short Duration
  121.  
  122.          Transaction communication sequences generally have short
  123.          duration, typically 100's of milliseconds up to 10's of
  124.          seconds, but never hours.
  125.  
  126.       *  Low Delay
  127.  
  128.          Some applications require minimal communication delay.
  129.  
  130.       *  Few Data Packets
  131.  
  132.          In many applications, the data to be sent can be compressed
  133.          into one or a few IP packets.  Applications which have been
  134.          designed with LAN's in mind are typically very careful to
  135.          minimize the number of data packets for each request/reply
  136.          sequence.
  137.  
  138.       *  Message Orientation
  139.  
  140.          The natural unit of data which is passed in a transaction is an
  141.          entire message ("record"), not a stream of bytes.
  142.  
  143. 3.  EXAMPLE: NAME SERVERS
  144.  
  145.    To focus our ideas, we will now discuss several particular types of
  146.    distributed applications which are of pressing concern to members of
  147.    the Internet research community, and which require
  148.    transaction-oriented communication.
  149.  
  150.    First, consider the name server/name resolver system [RFC-882,
  151.    RFC-883] which is currently being introduced into the (research)
  152.    Internet.  Name servers must use TCP and/or UDP as their transport
  153.    protocol.  TCP is appropriate for the bulk transfers needed to update
  154.    a name server's data base.  For this case, reliability is essential,
  155.    and virtual-circuit setup overhead is negligible compared to the data
  156.    transfer itself.  However, the choice of a transport protocol for the
  157.    transaction traffic -- queries and responses -- is problematic.
  158.  
  159.       *  TCP would provide reliable and flow-controlled transfer of
  160.          arbitrary-sized queries and responses.  However, TCP exacts a
  161.          high cost as a result of its circuit setup and teardown phases.
  162.  
  163.       *  UDP avoids the overhead of TCP connection setup.  However, UDP
  164.          has two potentially-serious problems -- (1) unreliable
  165.          communication, so that packets may be lost, duplicated, and/or
  166.  
  167.  
  168.  
  169. Braden                                                          [Page 3]
  170.  
  171.  
  172.  
  173. RFC 955                                                   September 1985
  174. Transaction Protocol
  175.  
  176.  
  177.          reordered; and (2) the limitation of a data object
  178.          (query/response) to the 548-byte maximum in a single UDP
  179.          packet.
  180.  
  181.    At present, name servers are being operated using UDP for transaction
  182.    communication.  Note that name server requests have a special
  183.    property, idempotency; as a result, lost, duplicated, or reordered
  184.    queries do not prevent the name-server system from working.  This
  185.    would seem to favor the use of UDP.
  186.  
  187.    However, it seems quite likely that the defects of UDP will make it
  188.    unusable for an increasing fraction of queries.
  189.  
  190.       *  The average size of individual replies will certainly increase,
  191.          as the more esoteric mail lookup features are used, as the host
  192.          population explodes (resulting in a logarithmic increase in
  193.          domain name sizes), and as the number of alternate acceptable
  194.          answers increases.  As a result, a single response will more
  195.          often overflow a single UDP packet.
  196.  
  197.       *  The average end-to-end reliability will decrease as some of the
  198.          flakier paths of the Internet are brought into use by name
  199.          resolvers.
  200.  
  201.          This will lead to a serious problem of choosing an appropriate
  202.          retransmission timeout.  A name resolver using UDP cannot
  203.          distinguish packet loss in the Internet from queueing delay in
  204.          the server.  As a result, name servers we have seen have chosen
  205.          long fixed timeouts (e.g., 30 seconds or more).  This will
  206.          result in long delays in name resolution when packets are lost.
  207.  
  208.          One might think that delays in name resolution might not be an
  209.          issue since most name lookups are done by a mailer daemon.
  210.          However, ARPANET experience with user mail interfaces has shown
  211.          that it is always desirable to verify the correctness of each
  212.          host name as the user enters the "To:" and "CC:" addresses for
  213.          a message. Hence, delays due to lost UDP packets will be
  214.          directly visible to users.
  215.  
  216.    More generally, the use of UDP violates sound communication system
  217.    design in two important ways:
  218.  
  219.       *  The name resolver/server applications have to provide timeouts
  220.          and retransmissions to protect against "errors" (losses) in the
  221.          communication system.  This certainly violates network
  222.          transparency, and requires the application to make decisions
  223.          for which it is not well-equipped.
  224.  
  225.  
  226. Braden                                                          [Page 4]
  227.  
  228.  
  229.  
  230. RFC 955                                                   September 1985
  231. Transaction Protocol
  232.  
  233.  
  234.          As a general design principle, it seems that (Inter-) network
  235.          properties, especially bad properties, ought to a large extent
  236.          to be hidden below the transport-service boundary [2].
  237.  
  238.       *  The name resolver/server applications must know the maximum
  239.          size of a UDP datagram.
  240.  
  241.          It is clearly wrong for an application program to contain
  242.          knowledge of the number 576 or 548!  This does not imply that
  243.          there cannot be a limitation on the size of a message, but any
  244.          such limitation should be imposed by the particular
  245.          application-level protocol, not the transport or internetwork
  246.          level.
  247.  
  248.    It seems that the TCP/UDP choice for name servers presents an ugly
  249.    dilemma.  We suggest that the solution should be a new
  250.    transaction-oriented transport protocol with the following features:
  251.  
  252.       *  Reliable ("at-least-once") Delivery of Data;
  253.  
  254.       *  No Explicit Connection Setup or Teardown Phases;
  255.  
  256.       *  Fragmentation and Reassembly of Messages;
  257.  
  258.       *  Minimal Idle State in both Client and Server.
  259.  
  260. 4.  ANOTHER EXAMPLE: DISTRIBUTED OPERATING SYSTEMS
  261.  
  262.    Distributed operating systems represent another potential application
  263.    for a transaction-oriented transport service.  A number of examples
  264.    of distributed operating systems have been built using high-speed
  265.    local area networks (LAN's) for communication (e.g, Cronus, Locus,
  266.    V-System).  Typically, these systems use private communication
  267.    protocols above the network layer, and the private transport-level
  268.    protocol is carefully designed to minimize latency across the LAN.
  269.    They make use of the inherent reliability of the LAN and of simple
  270.    transactions using single-packet exchanges.
  271.  
  272.    Recently there have been efforts to extend these systems to operate
  273.    across the Internet [Cher85, Shel85].  Since these are not "open"
  274.    systems, there is no requirement that they use a standard transport
  275.    protocol. However, the availability of a suitable transport protocol
  276.    for transactions could considerably simplify development of future
  277.    distributed systems.
  278.  
  279.    The essential requirement here seems to be packet economy.  The same
  280.  
  281.  
  282.  
  283. Braden                                                          [Page 5]
  284.  
  285.  
  286.  
  287. RFC 955                                                   September 1985
  288. Transaction Protocol
  289.  
  290.  
  291.    minimal two-packet exchange used over the LAN should be possible
  292.    across the Internet.  This leads to two requirements for supporting
  293.    distributed operating systems:
  294.  
  295.       *  No Explicit Connection Setup or Teardown Phases;
  296.  
  297.       *  Implicit ("piggy-backed") Acknowledgments Whenever Possible.
  298.  
  299.          This implies that the response packet will serve as an implicit
  300.          acknowledgment to the request packet (when timing makes this
  301.          possible).  Similarly, a new request (for the same pair of
  302.          addressable entities) would implicitly acknowledge the previous
  303.          response, if it came soon enough.
  304.  
  305.    The nature of the application imposes two other requirements:
  306.  
  307.       *  Reliable ("at-most-once"), Ordered Delivery
  308.  
  309.          However, it should be possible to relax the reliability to take
  310.          advantage of special cases like an idempotent request.
  311.  
  312.       *  Multicast Capability
  313.  
  314.          The transport service should mesh cleanly with the proposed
  315.          Internet multicast facility, using host groups [ChDe85].
  316.  
  317. 5.  OBJECTIVES FOR A PROTOCOL
  318.  
  319.    We believe that it is possible to design a new transport protocol for
  320.    the Internet which is suitable for a wide variety of
  321.    transaction-oriented applications.  Such a transport protocol would
  322.    have the following attributes:
  323.  
  324.       *  Reliable Delivery
  325.  
  326.          Data will be delivered reliably, i.e., exactly once, or the
  327.          sender will be informed.  The protocol must be able to handle
  328.          loss, duplication, and reordering of request and response
  329.          packets.  In particular, old duplicate request packets must not
  330.          cause erroneous actions.
  331.  
  332.          It should also be possible for the application programs to
  333.          request that the reliability be relaxed for particular
  334.          transactions.  This would allow communication economies in the
  335.          case of idempotent requests or of notification without reply.
  336.  
  337.  
  338.  
  339.  
  340. Braden                                                          [Page 6]
  341.  
  342.  
  343.  
  344. RFC 955                                                   September 1985
  345. Transaction Protocol
  346.  
  347.  
  348.       *  Minimum Number of Packets in Simple Cases
  349.  
  350.          In the simplest case (small messages, no packet losses, and the
  351.          interval between requests and replies between the same pair of
  352.          addressable entities shorter than applicable timeouts), a
  353.          simple two-packet exchange should result.
  354.  
  355.       *  No Explicit Connection Setup or Teardown Phases
  356.  
  357.          The protocol will not create virtual circuits, but will provide
  358.          what is sometimes (confusingly) called "reliable datagram"
  359.          service.
  360.  
  361.          However, in order to provide a minimum two-packet exchange,
  362.          there must be some implicit state or "soft" virtual circuit
  363.          between a pair of addressable entities. In recent discussions
  364.          this has been dubbed a "conversation", to distinguish it from a
  365.          connection.
  366.  
  367.       *  Minimal Idle State
  368.  
  369.          When a server is not processing a transaction, there will be no
  370.          state kept (except enough to recognize old duplicate packets
  371.          and to suppress unneeded ACK packets).
  372.  
  373.       *  Fragmentation/Reassembly of Large Messages
  374.  
  375.          There is a range of possible objectives here. The minimum
  376.          requirement is that the application not have to know the number
  377.          576, 548, etc. For example, each application might establish
  378.          its own "natural" upper limit on the size of a message, and
  379.          always provide a buffer of that size [3].
  380.  
  381.          At the other extreme, the protocol might allow very large
  382.          messages (e.g., a megabyte or more).  In this case, the
  383.          proposed protocol would, in the large-message limit, be
  384.          performing the bulk data transfer function of TCP.  It would be
  385.          interesting to know whether this is possible, although it is
  386.          not necessarily a requirement.
  387.  
  388.          The introduction of multi-packet messages leads to the complex
  389.          issues of window sizes and flow control.  The challenge is to
  390.          handle these efficiently in the absence of connection setup.
  391.  
  392.       *  Message Orientation
  393.  
  394.  
  395.  
  396.  
  397. Braden                                                          [Page 7]
  398.  
  399.  
  400.  
  401. RFC 955                                                   September 1985
  402. Transaction Protocol
  403.  
  404.  
  405.          The basic unit of communication will be an entire message, not
  406.          a stream of bytes.  If a message has to be segmented, it will
  407.          be delivered in units of segments or buffers, not bytes.
  408.  
  409.       *  Multicast Capability
  410.  
  411.    Based on this discussion, we can suggest some of the key issues and
  412.    problems in design of this protocol.
  413.  
  414.       *  Choice of Addressable Entity
  415.  
  416.          What will be the addressable entity?  It must be unique in
  417.          space; must it be unique in time (even across system crashes) ?
  418.  
  419.       *  Timeout Dynamics
  420.  
  421.          Timeouts must be the key to operation of this protocol.
  422.          Experience with TCP has shown the need for dynamic selection of
  423.          an appropriate timeout, since Internet delays range over four
  424.          decimal orders of magnitude.
  425.  
  426.          However, the absence of connection setup and the
  427.          typically-short duration of a single interaction seem to
  428.          preclude the dynamic measurement of delays.
  429.  
  430.       *  Multi-Packet Messages
  431.  
  432.          How can flow control be provided for multi-packet messages, to
  433.          provide reasonable throughput over long-delay paths without
  434.          overrun with short-delay paths, when there is no virtual
  435.          circuit setup?
  436.  
  437.       *  Implementation Efficiency
  438.  
  439.          The protocol should lend itself to efficient (which probably
  440.          implies simple) implementations, so that hosts will be willing
  441.          to use it over LAN's as well as for general Internet
  442.          communication.
  443.  
  444.    We believe further study is needed on these questions.
  445.  
  446.    The reader may wonder: how is the proposed protocol related to an RPC
  447.    (Remote Procedure Call) facility?  The intent is that RPC facilities
  448.    and message-passing IPC facilities will be built on top of the
  449.    proposed transport layer.  These higher-level mechanisms will need to
  450.    address a number of additional issues, which are not relevant to the
  451.    communication substrate:
  452.  
  453.  
  454. Braden                                                          [Page 8]
  455.  
  456.  
  457.  
  458. RFC 955                                                   September 1985
  459. Transaction Protocol
  460.  
  461.  
  462.       1.  Application Interface
  463.  
  464.          This includes binding and stub generators.
  465.  
  466.       2.  Structured Data Encoding
  467.  
  468.       3.  Server Location and Binding
  469.  
  470.       4.  Authentication and Access Control
  471.  
  472. 6.  CONCLUSION
  473.  
  474.    Distributed processing and distributed data bases will underlie many
  475.    of the future computer system research projects and applications
  476.    based upon the Internet.  As a result, transaction-based
  477.    communication will be an increasingly important activity on the
  478.    Internet.  We claim that there is a pressing need for an appropriate
  479.    transport protocol for transaction processing.  In this memo, we have
  480.    given examples to support this claim, and have outlined the service
  481.    which such a new transport protocol would provide.
  482.  
  483.    This memo is based upon discussions within the New End-to-End
  484.    Protocols taskforce, and it is a pleasure to acknowledge the
  485.    participation and sagacity of the members of that group.  I want to
  486.    thank Dave Clark, an ex officio taskforce member, for his
  487.    contribution to these discussions, and Robert Cole for very helpful
  488.    suggestions.
  489.  
  490. NOTES:
  491.  
  492.    [1]  For the purposes of this RFC, in fact, the reader may consider
  493.         "transport service" to be defined as that protocol layer which
  494.         contains TCP and UDP, as in Figure 1 of RFC-791.  Alternatively,
  495.         we may use the ISO definition -- the transport service is the
  496.         lowest layer providing end-to-end service which is essentially
  497.         independent of the characteristics of the particular (Inter-)
  498.         network used to support the communication.
  499.  
  500.    [2]  This idea is implicit in the ISO definition of a transport
  501.         service.
  502.  
  503.    [3]  It would be reasonable for the name server definition to specify
  504.         an upper bound on the size of a single query or response; e.g.,
  505.         2K bytes.  This would imply (large) limits on the number of RR's
  506.         that could be returned per response. If that limit is exceeded,
  507.         we are doing something wrong!
  508.  
  509.  
  510.  
  511. Braden                                                          [Page 9]
  512.  
  513.  
  514.  
  515. RFC 955                                                   September 1985
  516. Transaction Protocol
  517.  
  518.  
  519. REFERENCES
  520.  
  521.    BiNe84   Birrell, Andrew D. and Nelson, Bruce Jay, "Implementing
  522.             Remote Procedure Calls". ACM TOCS, Vol. 2, No. 1, February
  523.             1984.
  524.  
  525.    ChDe85   Cheriton, David R. and Deering, Steven, "Host Groups: a
  526.             Multicast Extension for Datagram Networks".  To be presented
  527.             to 9th Data Communication Symposium.
  528.  
  529.    Cher85   Cheriton, David R., "V Message Transaction Protocol".
  530.             Private communication, July 1985.
  531.  
  532.    Cour81   Xerox Corp., "Courier: The Remote Procedure Call Protocol".
  533.             XSIS 038112, Xerox Corp., Stamford, Conn., December 1981.
  534.  
  535.    Coop84   Cooper, Eric C., "Circus: a Replicated Procedure Call
  536.             Facility".  Proc. 4th Symposium on Reliability in
  537.             Distributed Software and Database Systems, October 1984.
  538.  
  539.    Crow85   Crowcroft, Jon, "A Sequential Exchange Protocol".  Internal
  540.             Note 1688, Computer Science Department, University College
  541.             London, June 1985.
  542.  
  543.    Gurw85   Gurwitz, Robert F., "Object Oriented Interprocess
  544.             Communication in the Internet".  Private communication,
  545.             April 1985.
  546.  
  547.    Mill85   Miller, Trudy, "Internet Reliable Transaction Protocol --
  548.             Functional and Interface Specification".  RFC-938, February
  549.             1985.
  550.  
  551.    Shel85   Sheltzer, Alan B. , "Network Transparency in an Internetwork
  552.             Environment", PhD Thesis, UCLA Department of Computer
  553.             Science, July 1985.
  554.  
  555.    Wats81   Watson, Richard W., "Timer-based Mechanisms in Reliable
  556.             Transport Protocol Connection Management".  Computer
  557.             Networks, Vol. 5, pp47-56, 1981 (also distributed as
  558.             IEN-193).
  559.  
  560.  
  561.  
  562.  
  563.  
  564.  
  565.  
  566.  
  567.  
  568. Braden                                                         [Page 10]
  569.  
  570.